home *** CD-ROM | disk | FTP | other *** search
/ MacFormat 1994 November / macformat-018.iso / Utility Spectacular / Developer / macgambit-20-compiler-src-p2 / Thomas / Thomas.README < prev   
Encoding:
Text File  |  1994-07-26  |  9.7 KB  |  219 lines  |  [TEXT/gamI]
  1. COPYRIGHTS
  2. ----------
  3.  
  4. For Thomas:
  5.  
  6. ;*              Copyright 1992 Digital Equipment Corporation
  7. ;*                         All Rights Reserved
  8. ;*
  9. ;* Permission to use, copy, and modify this software and its documentation is
  10. ;* hereby granted only under the following terms and conditions.  Both the
  11. ;* above copyright notice and this permission notice must appear in all copies
  12. ;* of the software, derivative works or modified versions, and any portions
  13. ;* thereof, and both notices must appear in supporting documentation.
  14. ;*
  15. ;* Users of this software agree to the terms and conditions set forth herein,
  16. ;* and hereby grant back to Digital a non-exclusive, unrestricted, royalty-free
  17. ;* right and license under any changes, enhancements or extensions made to the
  18. ;* core functions of the software, including but not limited to those affording
  19. ;* compatibility with other hardware or software environments, but excluding
  20. ;* applications which incorporate this software.  Users further agree to use
  21. ;* their best efforts to return to Digital any such changes, enhancements or
  22. ;* extensions that they make and inform Digital of noteworthy uses of this
  23. ;* software.  Correspondence should be provided to Digital at:
  24. ;*
  25. ;*                      Director, Cambridge Research Lab
  26. ;*                      Digital Equipment Corp
  27. ;*                      One Kendall Square, Bldg 700
  28. ;*                      Cambridge MA 02139
  29. ;*
  30. ;* This software may be distributed (but not offered for sale or transferred
  31. ;* for compensation) to third parties, provided such third parties agree to
  32. ;* abide by the terms and conditions of this notice.
  33. ;*
  34. ;* THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
  35. ;* WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF
  36. ;* MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
  37. ;* CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
  38. ;* DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
  39. ;* PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
  40. ;* ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
  41. ;* SOFTWARE.
  42.  
  43. For MacGambit:
  44.  
  45. MacGambit is copyright 1992-93 Universite de Montreal.  Check
  46. the "About MacGambit" dialog box in the apple menu for details.
  47.  
  48.  
  49. THOMAS OVERVIEW
  50. ---------------
  51.  
  52. Thomas is a compiler written at Digital Equipment Corporation's
  53. Cambridge Research Laboratory.  Thomas compiles a language compatible
  54. with the language described in the book "Dylan(TM) an object-oriented
  55. dynamic language" by Apple Computer Eastern Research and Technology,
  56. April 1992.
  57.  
  58. We have made every effort to minimize the differences between Thomas and
  59. Dylan(TM), and to remove bugs, but help from others would be greatly
  60. appreciated.  The original development team consisted of:
  61.  
  62.           Matt Birkholz (Birkholz@crl.dec.com)
  63.           Jim Miller (JMiller@crl.dec.com)
  64.           Ron Weiss (RWeiss@crl.dec.com)
  65.  
  66. In addition, Joel Bartlett (Bartlett@wrl.dec.com), Marc Feeley
  67. (Feeley@iro.umontreal.ca), Guillermo Rozas (Jinx@zurich.ai.mit.edu) and
  68. Ralph Swick (Swick@crl.dec.com) contributed time and energy to the initial
  69. release.
  70.  
  71. Comments, questions, suggestions, help, etc. should be directed to:
  72.           info-thomas@crl.dec.com
  73. Requests to be added to this mailing list should be sent to:
  74.           info-thomas-request@crl.dec.com
  75.  
  76.                                 * * *
  77.  
  78. In building Thomas, our goals (in order of priority) were:
  79.  
  80. (1) To learn about the Dylan(TM) language, by building an implementation
  81.     based solely on the description in the book.
  82.  
  83. (2) To help others learn about the language by producing source code for an
  84.     implementation that was well structured, easy to read, and was
  85.     publically available (the source code can be obtained via anonymous
  86.     FTP from crl.dec.com in the pub/DEC/Thomas directory).
  87.  
  88. (3) To build a system we could use to actually write small Dylan(TM)
  89.     programs, to get a feel for the language through using it.
  90.  
  91. We feel we have met these three goals as well as can be expected in a four
  92. week project with three people.  It was never our intention to produce an
  93. implementation that performs well, and Thomas has no optimizations of any
  94. kind.  It does not perform well.  This reflects our goals and not
  95. necessarily the design of the language itself.
  96.  
  97. Thomas is NOT Dylan(TM).  We have not received approval for the use of the
  98. trademark, and we have not received a copy of a test suite other than the
  99. examples from the book itself.  We may, at some future date, pursue these
  100. issues with Apple.  The Thomas system was built with no direct input, aid,
  101. assistance or discussion with Apple.  All design and implementation
  102. decisions in Thomas reflect choices by the Thomas implementors based on
  103. reading the book published by Apple.  These decisions must not be
  104. construed in any way as deriving from Apple Computer Corporation or its
  105. employees.
  106.  
  107.  
  108. KNOWN PROBLEMS IN THOMAS
  109. ------------------------
  110.  
  111. I. Known differences from the book "Dylan(TM) an object-oriented
  112.    dynamic language" by Apple Computer Eastern Research and
  113.    Technology, April 1992.
  114.  
  115. 1) In order to use Scheme's READ to handle Thomas expressions, Thomas
  116.    uses !key and !rest wherever the Dylan(TM) book uses #key or #rest.
  117.  
  118. 2) Thomas variable names are restricted to the subset of Scheme names
  119.    that don't start with "!" or "dylan:".  This avoids name clashes
  120.    between user variable names and compiler-generated variables.
  121.  
  122. 3) Thomas doesn't remember the initial case of symbols, since it
  123.    inherits the case from the underlying Scheme system.  Thus some
  124.    implementations of Thomas store symbols in upper case, some in
  125.    lower case, and some preserve case.  All implementations are
  126.    otherwise case-insensitive for symbols, keywords and variable
  127.    names.
  128.  
  129. 4) Thomas doesn't fully handle sealed classes, abstract classes, or
  130.    read-only module variables.
  131.  
  132. 5) Thomas doesn't support the REMOVE-SLOT operation.  We don't really
  133.    understand the full intent of this operation in a variety of
  134.    circumstances.
  135.  
  136. 6) Thomas doesn't do collection alignment for tables (as specified on
  137.    pages 128 and 129); other collection types should be OK.  Fixing
  138.    this would be a very nice contribution to the Thomas implementation
  139.    (hint, hint).
  140.  
  141. 7) Thomas doesn't do (SETTER DIRECT-SUPERCLASSES).  This is somewhere
  142.    between an oversight (we honestly didn't notice it and it isn't in
  143.    the index) and a pain to write.  Again, help would be appreciated.
  144.  
  145. 8) Thomas doesn't do virtual slots in a way that supports their use as
  146.    "filtered slots" as described on pages 58 and 59.  We find the
  147.    description confusing, and require implementors to allocate an
  148.    object of the supertype to store the "hidden" slot value rather
  149.    than relying on NEXT-METHOD to find the hidden slot in the object
  150.    itself.
  151.  
  152. 9) Some implementations of Scheme do not recognize the same set of literal
  153.    character names as specified in the book.  IEEE Scheme requires the
  154.    character literals #\space and #\newline.  Dylan also specifies
  155.    #\rubout, #\page, #\tab, #\backspace, #\return, and #\linefeed.
  156.  
  157. II. Additions to the Thomas language
  158.  
  159. Thomas provides four methods not mentioned in Dylan(TM):
  160.  
  161.      (display <object>)    derived from Scheme's DISPLAY
  162.      (newline)             derived from Scheme'S NEWLINE
  163.      (print <object>)      same as write-line
  164.      (write-line <object>) NEWLINE, then WRITE <object>
  165.  
  166. The MacGambit version of Thomas includes four additional predefined
  167. methods:
  168.  
  169.      (PP <object>) calls the Scheme pretty printer.  Useful to see the
  170.        Scheme code that was generated for a method.
  171.  
  172.      (SCHEME-VARIABLE <symbol>) returns the value of a Scheme variable
  173.        that is visible from the normal user interaction environment.
  174.        This can be used to access any Scheme object, but results are
  175.        unpredictable unless the object has a type that corresponds to
  176.        one of the non-procedural Thomas types.  Common types that can
  177.        be accessed this way are booleans, symbols, strings, numbers,
  178.        the empty list, as well as vectors or lists composed of these.
  179.  
  180.      (SCHEME-PROCEDURE <symbol>) also returns the value of a Scheme
  181.        variable that is visible from the normal user interaction
  182.        environment.  It assumes (without checking) that it is
  183.        applicable and converts it to a Thomas method.  From within
  184.        Thomas it will appear to take an arbitrary number of arguments,
  185.        but will issue an error if the number supplied doesn't match
  186.        the number expected by the Scheme procedure.
  187.  
  188.      (LOAD <string>) loads a file containing Thomas code.  The file is
  189.        first compiled into a Scheme program, which is then loaded with
  190.        Scheme's predefined load procedure.
  191.  
  192.  
  193. THOMAS 1.1 RELEASE NOTES
  194. ------------------------
  195.  
  196. Thomas version 1.1 contains the following changes from version 1.0:
  197.  
  198. * sorted-applicable-methods now uses a new topological sort that uses a
  199. number we call "class specificity".  Intuitively, class specificity
  200. increases every time a class is specialized to produce a subclass.
  201. Computationally, class specificity is the largest number of subclass links
  202. between <object> and the class.  For example, consider this class
  203. heterarchy:
  204.  
  205.               <object>     specificity = 0
  206.               /  |  \
  207.             <a> <b> <c>    specificity = 1
  208.               \ /   /
  209.               <d>  /       specificity = 2
  210.                 \ /
  211.                 <e>        specificity = 3
  212.  
  213. Thus, during method dispatch on an object of type <d>, Thomas considers
  214. methods specialized by class <d> to be more specific than those specialized
  215. by <a> or <b>, which are in turn more specific than any specialized by
  216. <object>.  Notice that the ordering of methods specialized by <a> and <b>
  217. is not specified.  Methods specialized on <e> or <c> are not applicable
  218. because <d> is not a subclass of either.
  219.